Subject: Additional objects for the APPN MIB

From: "R.E. (Robert) Moore (254-4436)" <[email-masked]>
Date: Wed, 16 Aug 95 13:11:16 EDT

At AIW7 I promised to get with Tim Hefel, to understand what new
capabilities in the APPN architecture should be reflected in the APPN
MIB.  Here's the set of new objects we came up with.  We can discuss
these Monday along with APPN.MIB.1 and the other comments on it.

Bob

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
appnNodeNnSafeStoreFreq     OBJECT-TYPE
      SYNTAX Integer32
      MAX-ACCESS read-write
      STATUS current
      DESCRIPTION
          "The topology safe store frequency.

           If the total number of topology database updates received
           by this node exceeds this non-zero value by an even multiple,
           the topology database is saved.  A value of zero indicates
           that the topology database is not being saved."

      ::=  { ibmappnNnUniqueInfoAndCaps 11 }

appnNodeNnUnknownCvsInTdu  OBJECT-TYPE
      SYNTAX INTEGER {yes(1), no(2)}
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
           "Indicates whether this node continues to process a TDU
           containing a control vector that it does not recognize."

      ::=  { appnNnUniqueInfoAndCaps 12 }

appnNodeNnEnhTopoDbGarbageColl  OBJECT-TYPE
      SYNTAX INTEGER {yes(1), no(2)}
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
           "Indicates whether this node supports enhanced garbage
           collection for its topology database."

      ::=  { appnNnUniqueInfoAndCaps 13 }

appnNodeNnTduWarDetection  OBJECT-TYPE
      SYNTAX INTEGER {yes(1), no(2)}
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
           "Indicates whether this node is able to detect and report
           TDU wars between itself and another network node."

      ::=  { appnNnUniqueInfoAndCaps 14 }

appnNodeNnCosOverride  OBJECT-TYPE
      SYNTAX INTEGER {yes(1), no(2)}
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
           "Indicates whether this node supports overriding of the
           COS values supplied by a user-specified set of served end
           nodes."

      ::=  { appnNnUniqueInfoAndCaps 15 }
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
appnNnTopoTotalTduWars OBJECT-TYPE
      SYNTAX Counter32
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
           "Number of TDU wars detected by this node since its last
           initialization."

      ::=  { appnNnTopo 24 }

appnNnTopoInGarbageCollTdus OBJECT-TYPE
      SYNTAX Counter32
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
           "Number of TDUs containing garbage-collected resource updates
           received by this node since its last initialization."

      ::=  { appnNnTopo 25 }

appnNnTopoOutGarbageCollTdus OBJECT-TYPE
      SYNTAX Counter32
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
           "Number of TDUs containing garbage-collected resource updates
           sent by this node since its last initialization."

      ::=  { appnNnTopo 26 }

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
AppnNnAdjNodeEntry ::= SEQUENCE {
      appnNnAdjNodeAdjName            DisplayString,
      appnNnAdjNodeCpCpSessStatus     INTEGER,
      appnNnAdjNodeOutOfSeqTdus       Gauge32,
      appnNnAdjNodeLastFrsnSent       INTEGER,
      appnNnAdjNodeLastFrsnRcvd       INTEGER,
      appnNnAdjNodeUnkCvsInTdu        INTEGER
                                   }

appnNnAdjNodeUnkCvsInTdu  OBJECT-TYPE
      SYNTAX INTEGER {yes(1), no(2)}
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
           "Indicates whether the adjacent node continues to process a
           TDU containing a control vector that it does not recognize."

      ::=  { appnNnAdjNodeEntry 6 }

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-- Make the same additions to AppnNnTopologyFREntry --
AppnNnTopologyEntry  ::= SEQUENCE {

      appnNnNodeName                     DisplayString,
      appnNnNodeFrsn                     INTEGER,
      appnNnNodeEntryTimeLeft            INTEGER,
      appnNnNodeType                     INTEGER,

      appnNnNodeRsn                      INTEGER,
      appnNnNodeRouteAddResist           INTEGER,
      appnNnNodeCongested                INTEGER,
      appnNnNodeIsrDepleted              INTEGER,
      appnNnNodeEndptDepleted            INTEGER,
      appnNnNodeQuiescing                INTEGER,
      appnNnNodeGateway                  INTEGER,
      appnNnNodeCentralDirectory         INTEGER,
      appnNnNodeIsr                      INTEGER,
      appnNnNodeChainSupport             INTEGER,
      appnNnNodeGarbageCollect           INTEGER,

      appnNnNodeHprSup                   INTEGER,
      appnNnNodeHprTrans                 INTEGER,
      appnNnNodePeriBorderSup            INTEGER,
      appnNnNodeInterchangeSup           INTEGER,
      appnNnNodeExteBorderSup            INTEGER,
      appnNnNodeCtrlFlowsOverRtp         INTEGER
}

appnNnNodeCtrlFlowsOverRtp OBJECT-TYPE
      SYNTAX INTEGER {yes(1), no(2)}
      MAX-ACCESS read-only
      STATUS current
      DESCRIPTION
          "Indicates whether this network node supports sending and
           receiving control flows over RTP connections.

      ::=  { appnNnTopologyEntry 21 }
+++++++++++++++++++++++++++++ END ++++++++++++++++++++++++++++++++++++

---

From: Bob Clouston <[email-masked]>
Date: Sat, 26 Aug 95 12:12:34 EDT

> these Monday along with APPN.MIB.1 and the other comments on it.

Does any product really do an incremental safe store like this?
It can cause CP-CP session failure upon restart very easily.
Part of safe store is storing adjacent node last FRSN sent and received,
so that you reduce TDU exchange when the node comes back up.
Suppose NNA's safe store frequency is every 10 TDUs.  It does a safe store
at FRSN 10, and goes down after sending a TDU with FRSN 15 to NNB.
When NNA comes back up, on CP Capabilities exchange NNB will have claimed
to have last received FRSN 15 from NNA, which puts it ahead of what NNA
remembers sending.  NNA treats this as a protocol violation and will
unbind CP-CP sessions with sense 08A00006.
To make topology safe store work right, you have to either safe store
on every TDU, or safe store on shutdown only.
If someone can show me how incremental safe store can be made to reduce
TDU flows effectively, I'm for keeping this, but unless that happens this
should not be added to the MIB.

> appnNodeNnTduWarDetection  OBJECT-TYPE

How would a customer use these?  It takes a good deal of TRS knowledge to
know how to use this information.  And aren't these base functions, so that
by the time this MIB is implemented they should pretty much be constants?
I'd rather keep them out of the MIB.

> appnNodeNnCosOverride  OBJECT-TYPE

Looks useful.  Should this read-write, or is this not a dynamic variable?

Don't we already have an APPN Alert (and therefore a trap with the TDU War
Alert ID) to inform the operator of each of these?  What is the value
of adding a counter as well?  Is this a supplement to the Alert/trap since
there may not be an Alert catcher and the trap may not be implemented?
With this counter, you can't tell which resource is in question.  A better
way would be to add this counter on each node and TG as well, so when
the total counter moves you can check each resource counter for movement.
I'd prefer to see everyone implement the trap instead.

> appnNnTopoOutGarbageCollTdus OBJECT-TYPE

I don't see the value of counting these.  A manager can just as easily
look at the garbage collect flag on resources to know when to delete them.
What would the counters tell anyone?

I had already targetted this table for removal, and I don't see enough
value in this object to keep it alive.

If we adopt my appnNnNodeCvs object proposal this value will be picked up 
automatically.

> +++++++++++++++++++++++++++++ END ++++++++++++++++++++++++++++++++++++

Bob Clouston